Doing this is a bad idea, as it'll break cards for other systems. If we ever offer an option to format a card on the device with linux filesystems it'd make sense to default to the user creating the card, but changing UIDs on unsupported cards on insertion without telling the user is bad.

Is there a link to MB#1010?

@foolab should be MER#1010 - my bad but : https://bugs.merproject.org/show_bug.cgi?id=1010

@bwachter I see your point but any linuxy SD card (ext/xfs/btrfs) is going to suffer from the mismatched UIDs problem (my UID is 500 on my desktop). If you insert an ext* formatted card into a device that claimes to supports ext* fs then you expect to be able to write to it in some manner.
It would be nice to send a notification that the root dir of the fs has been changed to allow the card to be written to. Is there a standard cli way to access the notification system that sd-utils can sensible Require: ?
If so then a media/ UID test and a notification on change would be a nice touch.

should be lipstick-qt5-tools

usage: https://github.com/nemomobile/lipstick/blob/master/tools/notificationtool/notificationtool.cpp#L77

@lbt a) we don't claim to support linux file systems on the SD card (and doing so would be rather stupid and cause a high care volume) b) changing the uid on / (apart from being unexpected by the user) does not solve the core problem of the filesystem having uids/gids not compatible with the system running on the phone. A variety of random issues will show up, like not being able to write to (some) subdirectories, not capable of accessing the pictures folder, the phone not indexing media due to lack of read permissions, ...

The only usecase of linux filesystems supportable easily is if the filesystem gets created on the phone, and the card is never removed and written on by another device, which -- unless the card gets glued in -- is unrealistic.

A way to properly have data read from a card with such a filesystem without destroying permissions would be an overlay filesystem, like we're using for the vfat emulation for androids fake sd card.

I could not find the bug for whatever reason but anyway:

If we change the uid manually then you will have issues when you try to access it from your PC/laptop.
I would also assume that if a user uses ext* then he knows what he is doing.
I would not do a UID change behind the user's back but how about we make that part configurable? The user can then edit a configuration file to choose the behavior he wants.

Another option is to autocreate directory (if it does not exist) with specific name (e.g. .nemo) on such sd cards with proper ownership and permissions and use this directory.

Agree with @bwachter and @foolab. Also, on the Desktop, the UID of 500 might not apply for all installations (e.g. on Fedora, I have UID=1000 for the first user, and once you have multiple users, all bets are off, anyway).

I'm against making it configurable. Either the user knows what they do (and can become root / do chown on their own) or they don't, in which case the emulated storage or reformatting the card as vfat is probably the best idea.

Android's version of emulate-user-permissions-on-top-of-native-permissions thing is here (it does some more things, and expects to "own" the underlying physical directory, but can be used as inspiration):
https://github.com/android/platform_system_core/blob/master/sdcard/sdcard.c

Also, see it the other way around: The SD card that previously worked perfectly on the Desktop machine (with UID=500 or UID=1000, or whatever the user has) stops working once the SD card has been put into a Nemo device, which changed permissions. Not good.

Detect the case and show a notification to the user, leave everything else up to the user (but allow re-formatting of the card as vfat for beginner users who just don't want to deal with this).

For comparison, OS X uses HFS+, which has Unix-style permissions, and for the usual "USB drive" cases, there's an "Ignore ownership and permissions" checkbox ("Instead, each item on the volume takes on a special UID and GID that tell the operating system to act as if any account that accesses the item is the item’s owner." -- Macintosh Reference Guide - Ignoring Ownership). There's no such agreed-upon UID in the Desktop Linux world, so this might not be an option, but just to show how others have solved this problem.

Alternative solution: #18